[00:00.000 --> 00:09.480]  Hi everyone, and welcome to How Do We Uniform November Foxtrot Uniform Charlie Kilo Unfuck
[00:09.480 --> 00:17.920]  Things. Can we really unfuck these things, or is it GARFU? And for those that don't know
[00:17.920 --> 00:26.540]  the military slang, this is... well, go Google it. It's more fun, right? I don't want to
[00:26.540 --> 00:34.520]  tell it all to you guys. Just go Google that. This talk is not your normal talk, right?
[00:34.520 --> 00:39.240]  This is an interpretive dance. This is me getting on my soapbox because I'm five foot
[00:39.240 --> 00:44.700]  nothing and tell you all the things that needs to be unfucked. This is my own opinion. This
[00:44.700 --> 00:48.800]  is no one else's opinion. This is conversations that have been had. This is observations that
[00:48.800 --> 00:54.580]  have been made. So if you're easily offended, this is not the talk for you. Scroll past,
[00:54.580 --> 01:05.520]  go do some other fluffy stuff. So who am I? I am a DEFCON goon. I'm the founder of DEC2751.
[01:05.620 --> 01:13.020]  We solely focus on reverse engineering medical devices and making things better. I'm also
[01:13.020 --> 01:19.360]  an avid biohacker village supporter. I think this is the best village at DEFCON. It's the
[01:19.360 --> 01:26.120]  one I certainly most enjoy. I'm also a current and independent researcher for Medtronic. And
[01:26.120 --> 01:33.720]  as you can see in the beautiful picture on the right, that is my Medtronic ICDR. It's what keeps
[01:33.720 --> 01:40.840]  me breathing and kicking and doing all the things. I'm also a DFIR lethal forensicator. I've been
[01:40.840 --> 01:46.660]  doing forensics and incident response for many, many years. Yes, I look very young, but I'm much
[01:46.660 --> 01:52.560]  older than I look. I'm a member of I Am The Calvary. I'm a patient and I proudly refer to
[01:52.560 --> 02:02.080]  myself as a cyborg. Now, I wanted to do a different talk this year because I believe that if we know
[02:02.080 --> 02:09.540]  what is wrong, we can find ways to fix them. So this is the talk for all medical device enthusiasts.
[02:09.540 --> 02:14.550]  Those that want to unfuck the things, those that want to fix it and make it better.
[02:16.080 --> 02:22.600]  So let's talk about the legacy of all problems, right? I sat down the day and I did the maths.
[02:22.600 --> 02:30.320]  In the US alone, there are 600,000 new implantable devices every year. These devices
[02:30.980 --> 02:37.260]  last for approximately a decade. So you start adding these up,
[02:37.260 --> 02:44.420]  we have a whole sea of devices that sooner or later will add to our technical debt.
[02:45.220 --> 02:52.440]  In a single hospital, if you put all the devices together within a hospital in the US,
[02:52.440 --> 02:59.320]  we'll have 10 to 15 million connected medical devices. That's about 10 to 15 connected devices
[02:59.320 --> 03:06.340]  per patient bed. To give you an example, I was in ICU because often than not, my heart's an asshole.
[03:07.010 --> 03:14.180]  And it lands me into ICU for some TLC, right? So I go have my holidays. If you look around,
[03:14.180 --> 03:21.220]  you have infusion pumps, you have monitors, you have external monitors monitoring your pacemaker
[03:21.220 --> 03:31.700]  or your ICD. And you have central stations. It is this big ocean of leaping lights. I know Jason
[03:31.700 --> 03:38.120]  Street always refers to it as a box with lengthy lights. Well, go be in an ICU bed, you'll see lots
[03:38.120 --> 03:44.380]  of those. So when we start realizing how many hospital beds there are, how many devices are
[03:44.380 --> 03:50.440]  attached to those beds, we start seeing the magnitude of the legacy. We see the ocean of
[03:50.440 --> 03:57.580]  devices we are faced to protect or to fix. Now, this is what led me down this path,
[03:57.580 --> 04:02.540]  is that I think we should start fixing the ship now. We can't wait for another year,
[04:02.540 --> 04:05.840]  can't wait for two, because we're adding to our problem.
[04:07.380 --> 04:11.460]  And now as we've seen COVID, healthcare has changed forever.
[04:11.820 --> 04:15.720]  The boundaries have been broken, the perimeters no longer exist.
[04:17.900 --> 04:23.620]  So you wonder why I say the legacy. Well, in case you did not know, most medical devices are coded
[04:23.620 --> 04:35.630]  in C. So I decided to do a dad joke. The question is, how are we getting it so wrong? And yeah,
[04:35.630 --> 04:42.810]  this someone said that someone was me. I want to know why in three years we've made no strides or
[04:42.810 --> 04:49.350]  why in three years we're doing the same things over and over. Well, let's start at the beginning.
[04:49.490 --> 04:55.050]  Lack of clear definitions. There's no consistencies in the terms that we use.
[04:55.650 --> 05:02.910]  I often go to talks and I realize, well, we're talking about medical device security, but the
[05:02.910 --> 05:08.910]  more that we are listening, I realize it is a Windows 10 endpoint within a healthcare establishment
[05:08.910 --> 05:15.670]  that we're talking about. Surely that's not the same as an insulin pump, an infusion pump, or even
[05:15.810 --> 05:22.430]  a pacemaker. Those things don't even look or act the same. So I decided to do what any good researcher
[05:22.430 --> 05:28.630]  does and I went to the dictionary. I looked up the terms. So let's explore healthcare.
[05:29.430 --> 05:35.250]  The field concerned with the maintenance and restoration of the health of the body and mind.
[05:37.330 --> 05:43.490]  It's hard, but this is what healthcare does. This is what hospitals do.
[05:44.010 --> 05:50.610]  So surely any device that they put there to help facilitate this should be called a healthcare
[05:50.610 --> 05:59.490]  device. So let's explore what is the meaning of medical relating to medicine or the practice of
[05:59.490 --> 06:06.110]  medicine. So it is something that allows us to practice medicine. Healthcare is something that
[06:06.110 --> 06:14.330]  we give to our patients. For me, I started to see the clear separation between the two.
[06:14.530 --> 06:19.970]  Each one has different responsibilities. Each one has a different function. It is very important
[06:19.970 --> 06:26.390]  that we start differentiating from the two. An interesting useless fact. Did you know that
[06:26.530 --> 06:33.490]  a cotton swab is seen as a medical device? Yes, that is for ICD-10 and billing purposes.
[06:34.310 --> 06:37.970]  I sure as hell don't think it's a device. I think it's a disposable.
[06:38.010 --> 06:43.970]  It's something we only use once. So let's see. What is a device?
[06:43.990 --> 06:49.430]  Something contrived for a specific purpose, usually a simple mechanical apparatus.
[06:49.970 --> 06:57.250]  Okay, so your insulin pump, your pacemaker, those are all a device, right?
[06:57.790 --> 07:03.830]  Well, now the question is, is it medical or is it healthcare? We need to start differentiating
[07:03.830 --> 07:09.830]  because each one of the two have different controls, different threats, different weaknesses
[07:09.830 --> 07:16.470]  and vulnerabilities. In fact, they have different operating systems. We need to clearly understand
[07:17.070 --> 07:23.850]  what we are dealing with. Now the question is, is it a healthcare or a medical device?
[07:23.850 --> 07:31.090]  Which button will you choose? Which one will you use? I get very confused because we're using the
[07:31.090 --> 07:36.930]  same terminology for everything because medical device sounds much more sexier than a healthcare
[07:36.930 --> 07:44.450]  endpoint or a healthcare device. But that leads me to the point that if we don't start defining
[07:44.450 --> 07:51.050]  these things out and understanding the ecosystem we are set to protect, we are setting ourselves
[07:51.050 --> 08:01.150]  up for a hiding. We are literally looking to be spanked. This is something that I'm living my
[08:01.150 --> 08:05.950]  life towards. When you talk, you are only repeating what you know, but when you listen,
[08:05.950 --> 08:13.230]  you learn something new. So I went on a year-long journey to understand what devices are telling me.
[08:13.230 --> 08:17.370]  I wanted to know what secrets they hold.
[08:20.220 --> 08:27.260]  Why things are so wrong is that we're not assigning responsibility accurately. I know
[08:27.260 --> 08:31.560]  it's a word that everyone fears because no one wants to be accountable or responsible
[08:32.160 --> 08:38.760]  for decisions or things they fault. So let's explore the MDM or the medical device
[08:38.760 --> 08:47.220]  manufacturer's responsibility. They have a responsibility to create devices that aren't
[08:47.220 --> 08:51.900]  unhackable because let's face it, nothing's unhackable. Everyone gets bored and someone
[08:51.900 --> 09:00.280]  figures out how to hack a device. But they need to have a device that is secure or as secure and
[09:00.280 --> 09:07.100]  safe as you can have it. But their responsibility is to deal with the devices both pre-market and
[09:07.100 --> 09:13.940]  post-market. Meaning that if a vulnerability is found pre-market, they need to fix it before going
[09:13.940 --> 09:19.380]  to market with the device. They need to do everything in their power to make sure what
[09:19.380 --> 09:24.280]  they are building, both on a firmware and a hardware level, takes into consideration the
[09:24.280 --> 09:30.880]  security challenges as well as the clinical features. Because let's face it, security is
[09:30.880 --> 09:37.080]  not a functional requirement for medical devices. They are there to offer medical care to patients.
[09:38.000 --> 09:44.440]  Often we see that security is slapped on after the fact, where it should be coming from design
[09:44.440 --> 09:51.560]  throughout manufacturing to when it goes to market. Now we have a fairly secure device that's
[09:51.560 --> 09:58.580]  gone to market. For example, an ICD lasts for 10 to 15 years. I can almost guarantee you that in
[09:58.580 --> 10:04.500]  that time, someone will find a vulnerability. Now we need to fix that vulnerability.
[10:05.200 --> 10:11.500]  The hospital or healthcare establishment has no power to fix the firmware or even fix the
[10:11.500 --> 10:17.690]  physical device if there's a vulnerability found. This remains the MDM's responsibility.
[10:18.420 --> 10:23.400]  Part of their responsibility is having a catalog or register of the information on everything that
[10:23.400 --> 10:29.180]  goes into their products. For every product they put on market, they have responsibility
[10:29.180 --> 10:32.560]  towards the end of the lifetime of that device.
[10:33.380 --> 10:39.280]  If it breaks, they are the only ones that have the power to fix it. No one else.
[10:41.200 --> 10:51.500]  Now we get to what is the FDA's responsibility? Well, I say the FDA because it's a US conference,
[10:51.500 --> 10:57.400]  but everyone follows suit of the FDA. If you start researching medical legislation around the world,
[10:57.400 --> 11:02.740]  you will see the terminology used by the FDA being rolled out in other countries,
[11:02.740 --> 11:07.220]  meaning they are the leader in this. They are the one that everyone looks up to.
[11:07.720 --> 11:15.760]  They need more legislative power. They need more teeth. They need to be an enforcer of
[11:15.760 --> 11:23.380]  what the standard is. They're the one that has to keep the MDM's on track. They are the ones
[11:23.380 --> 11:28.500]  that gatekeepers to the market for products. They are the ones that need to enforce the
[11:28.500 --> 11:35.480]  fixing of the problem. I know that they're currently working on new guidances, and I
[11:35.480 --> 11:41.820]  surely hope that it's got more teeth. An example of this is in the guidances currently at state,
[11:41.820 --> 11:48.440]  reasonable risk analysis needs to be done. However, the reasonable analysis that is required
[11:48.440 --> 11:55.600]  for it to meet the reasonable test is not specified. So again, we have guidances that
[11:55.600 --> 12:03.140]  don't have enough detail or standards out. I'm hoping that from a legislative point of view,
[12:03.140 --> 12:08.020]  we can actually start setting the tone of what is expected from a medical device,
[12:08.020 --> 12:14.440]  both on a clinical and both at a security level. And this is not just for implantables.
[12:14.440 --> 12:22.480]  I know it's a little bit harder when it's inside someone, but let's start categorizing it.
[12:22.480 --> 12:27.080]  Let's start standardizing the things and setting up the rules of engagement.
[12:28.020 --> 12:34.940]  What is expected of a device? How should it be used and how it should be updated? These are
[12:34.940 --> 12:41.520]  things that only can be done by the FDA. They are the rule setters. They are the rule enforcers.
[12:41.520 --> 12:50.620]  Let me look at what is the HDO's responsibility. Their responsibility is to keep their patients
[12:50.620 --> 12:59.520]  alive. Their responsibility is to have these diversities of devices on their networks,
[12:59.520 --> 13:07.200]  but they have to implement them in a safe way, taking into consideration the type of device it
[13:07.200 --> 13:14.240]  is, how it communicates, and how they are going to introduce it into their ecosystem.
[13:14.600 --> 13:22.480]  Those are the responsibilities of the HDO. They do not hold a responsibility for updating firmware
[13:22.940 --> 13:30.200]  or even vulnerability management of devices. That should be a manufacturing role.
[13:30.720 --> 13:39.460]  We've seen that during COVID-19, HDO's are crumbling globally. Healthcare is fracturing.
[13:39.820 --> 13:45.980]  And the fact is that they are designed, their purpose is to deal with pandemics and viruses.
[13:46.240 --> 13:52.400]  We are now expecting them to take on board cybersecurity and do the job of the manufacturer
[13:52.400 --> 13:59.480]  or do the job of the FDA. That is not what they're designed for. So how can we expect that
[13:59.480 --> 14:05.920]  they will not crumble and break even further? As a security researcher or a hacker, I don't
[14:05.920 --> 14:10.700]  want to be responsible for breaking healthcare more. I want to be responsible for making it
[14:10.700 --> 14:17.080]  better. So we should take into consideration that the decisions they make on a daily basis
[14:17.080 --> 14:24.080]  are life and death. They have patients connected to them. We shouldn't be making things harder for
[14:24.080 --> 14:31.600]  an HDO. We should be supporting them and making it safer for them to implement. The last thing I
[14:31.600 --> 14:38.040]  want is for someone to have a device breached and a patient to lose their life. It puts signs back
[14:38.040 --> 14:44.700]  tens of decades. And the fact of the matter is I would not be here without my device.
[14:44.720 --> 14:52.740]  I would be dead at the age of 19. It has extended my life and for that I'm grateful and thankful.
[14:53.200 --> 14:59.420]  So we cannot go forward and break things more until we have an understanding how we can build
[14:59.420 --> 15:09.520]  them up. Now the third problem is two worlds colliding, meaning we have this complex ecosystem
[15:10.400 --> 15:16.460]  that has different devices but we have one way of implementing them. We have a cookie
[15:16.460 --> 15:20.420]  cutter approach when it comes to infusing medical devices into a hospital
[15:21.480 --> 15:29.540]  because we don't define these out properly. Are we heading for a big bang or is it going to be
[15:29.680 --> 15:36.800]  a meeting of the minds? I think we are facing a situation where we're going to have a big bang
[15:38.120 --> 15:47.120]  because all we need to happen is for these controls to fail. And can you honestly tell me
[15:47.120 --> 15:53.200]  that you have the same controls for a Windows 10 machine versus a patient bedside monitor
[15:53.200 --> 16:00.240]  running something like BusyBox, VXWorks or proprietary software? Are these the same?
[16:00.240 --> 16:06.340]  Do they look the same? Do they sound the same? Do they crack the same? I don't think so. I think
[16:06.340 --> 16:13.000]  each one comes with different sets of challenges. I found that a hospital is the most complex
[16:13.780 --> 16:19.860]  sea of devices that I've ever seen and this is just me walking through a hospital. Have you
[16:19.860 --> 16:26.220]  ever noticed how many different manufacturers can be under one roof? Do you think that those
[16:27.480 --> 16:32.860]  devices are all made equally and the same? Do you think every manufacturer implies
[16:33.480 --> 16:41.080]  the same controls? Has the same way of thinking? No, everyone functions in a silo because there's
[16:41.080 --> 16:47.800]  no clear standard. The standards we are using are those for IoT devices or for regular computers
[16:47.800 --> 16:55.820]  or laptops or endpoints. There's no set of standards specifically catering to medical devices.
[16:56.320 --> 17:02.280]  And to be clear, when I say medical device, I mean that thing made by a manufacturer.
[17:02.860 --> 17:07.740]  Not a Windows 10 running software. That's a different conversation.
[17:11.090 --> 17:16.510]  Again, leading into this, it's the diversity of it all.
[17:17.730 --> 17:22.790]  Have you ever spent time in a hospital and just looked around
[17:24.230 --> 17:31.050]  and then think to yourself, I wonder how they've implemented this? A lot of hospitals will offer
[17:31.390 --> 17:41.610]  Wi-Fi. Those systems are often not segmented. There's the saying in security, trust but verify.
[17:41.830 --> 17:46.990]  Right? We just give everyone access. All the systems have access to everything
[17:47.670 --> 17:55.190]  because we want to make it easier. Now I ask you, if you look at this picture,
[17:55.190 --> 18:03.330]  most of those devices are connected onto the hospital network. These devices all have
[18:03.330 --> 18:12.710]  communications. But all these devices are most likely very different in how they apply security.
[18:12.750 --> 18:17.290]  And let me tell you, often we do this thing where security is an afterthought
[18:17.290 --> 18:25.070]  or a post-market situation. We don't give developers or hardware engineers
[18:26.210 --> 18:34.430]  the information to become security-minded developers, security-minded hardware engineers.
[18:34.670 --> 18:42.190]  Security can be built into every portion of your pipeline and should be. We should be taking this
[18:42.190 --> 18:50.110]  as a requirement to look at. I'm also big that one day these devices will be hacked. In fact,
[18:50.110 --> 18:55.930]  they might already be hacked because we don't have the data to pull from to say whether or
[18:55.930 --> 19:02.410]  not the device has been hacked. Always in incident response, we come after the fact and say,
[19:02.410 --> 19:08.010]  oh, if I only had logs, oh, if I only had this piece of evidence. We should be building in
[19:08.010 --> 19:15.130]  these controls to be able to visualize what's going on on the device. Now you might ask how I
[19:15.130 --> 19:22.190]  know this. Well, I have a whole room filled with medical devices. I have a whole library filled
[19:22.190 --> 19:28.130]  with firmware. I have been doing forensics for the last year. I'm trying to determine whether or not
[19:28.130 --> 19:34.430]  there's any logging or whether or not I even have the ability to do a forensic investigation.
[19:34.430 --> 19:40.490]  And I can tell you that no, because no one considers the fact that these devices
[19:40.490 --> 19:45.610]  will inevitably one day get reached if they have not already.
[19:46.850 --> 19:53.650]  A big thing that I want to see change is that we have proper standards and rigorous guidances.
[19:54.030 --> 20:00.730]  These things should be enforced. They should not be if you want to do the following.
[20:01.080 --> 20:07.220]  There should be repercussions for MDM not following standards and guidances.
[20:08.310 --> 20:14.360]  I have spent significant time looking at the NIST standards currently used for medical devices.
[20:15.250 --> 20:24.500]  These things are referencing machines that have Windows or Microsoft or different protocols.
[20:24.500 --> 20:32.040]  They don't take into consideration what a medical device is. I want to see controls.
[20:32.140 --> 20:38.640]  Controls are there for specific devices, but we need to categorize these first.
[20:38.840 --> 20:43.980]  And I think before we get ahead, the first and foremost thing that needs to change is the fact
[20:43.980 --> 20:50.720]  that we need to start understanding what a medical device is as well as subcategories of that device.
[20:51.460 --> 20:57.800]  I think once we have clearer understanding, we can have better standards.
[20:58.040 --> 21:03.140]  I would love to see a NIST standard specifically catering to medical devices,
[21:03.640 --> 21:08.720]  specifically taking into consideration the unique challenges they face.
[21:12.040 --> 21:21.000]  And how do I know these things? Data never lies. It's the one thing that you can listen to.
[21:21.000 --> 21:28.260]  Yes, data can be manipulated, but this is data that's collected over long periods of time.
[21:29.040 --> 21:35.500]  Healthcare has become the biggest target at the moment. Not only are they facing keeping people
[21:35.500 --> 21:43.400]  alive, they are facing attacks from all avenues. The internal threat or the malicious actor from
[21:43.400 --> 21:50.080]  within has certainly taken a rise. I was very shocked to learn the other day that 18% of
[21:50.080 --> 21:57.160]  healthcare workers stated that they would sell patient records for the right price.
[21:57.460 --> 22:01.580]  We never consider that the greatest threat might come from within.
[22:04.130 --> 22:10.350]  So now we've spoken a lot about the problems, but there is a saving grace. There's something
[22:10.350 --> 22:16.990]  that I really believe has the right approach to dealing with the complex problem that is
[22:16.990 --> 22:22.750]  medical devices within a hospital. It is called the Zero Trust Network.
[22:23.530 --> 22:30.490]  Trust is neither a zero nor a one. This turns the whole security on its head, where we no longer
[22:30.490 --> 22:37.150]  just trust but verify. We verify but never trust. We no longer have this perimeter-based defense
[22:37.150 --> 22:45.010]  structure that we used to have. I think most hospitals build this huge wall and make their
[22:45.010 --> 22:51.370]  perimeter hard, but never considering that patients walk in and out of a hospital wearing
[22:51.370 --> 22:59.840]  wearables with embedded devices or, you know, introducing medical devices that are connected.
[23:00.590 --> 23:09.090]  I've often seen that hospitals get breached via a phishing email or via a system that
[23:09.090 --> 23:16.390]  should not have access to the whole entire network. This is a very important thing for me,
[23:16.390 --> 23:22.690]  because this could lead to us defining that, you know, the least privilege and the least access
[23:22.690 --> 23:28.750]  that a device should have on a network. And especially with electronic healthcare records
[23:28.750 --> 23:36.590]  moving to the cloud, not every system needs to have access to that. We should be limiting what
[23:36.590 --> 23:43.310]  devices have access and how they have access. And I think one of the biggest things and the
[23:43.310 --> 23:49.030]  most promising things is if we find that a device is no longer conforming to the rules and the
[23:49.030 --> 23:57.410]  controls we've set up, you can revoke the access for that device. It breaks down the perimeter
[23:57.410 --> 24:03.550]  and makes it more secure. It makes it more manageable, because now we have the ability
[24:04.190 --> 24:11.610]  to differentiate between devices and we don't have to have a cookie-cutter approach
[24:11.610 --> 24:21.770]  to healthcare security. Another big thing I realized is us as researchers or the FDA or the MDM,
[24:21.770 --> 24:27.590]  we don't like to play nice together. We don't like to listen to someone that has a difference
[24:27.590 --> 24:36.050]  of opinion than we do. We don't like criticism. We don't like to debate situations. But the fact
[24:36.050 --> 24:42.070]  remains that working together is the only way that we get to solve healthcare. After all,
[24:42.070 --> 24:50.570]  it takes a village or even two for that to even happen. I think it's a smarter way
[24:50.970 --> 24:56.990]  to pull resources together and hit this problem from all sides.
[24:56.990 --> 25:02.850]  It needs to be a multidisciplinary approach to solving the problem that is healthcare and
[25:02.850 --> 25:10.310]  medical device security. So let's see some solutions. We need to define things better.
[25:10.590 --> 25:15.410]  We need to assign the responsibility and accountability to the parties involved.
[25:16.190 --> 25:24.770]  We need to not trust implicitly. We should not put devices into our networks and trust them
[25:24.770 --> 25:31.150]  with the keys to the kingdom. We should assume that a device is breached at all times,
[25:31.150 --> 25:37.710]  because most likely it is, because you don't know otherwise. At one point of time, we are gonna
[25:37.710 --> 25:46.210]  see medical devices breached. Well, they might already be. We need to standardize and set the
[25:46.210 --> 25:52.430]  tone, the rules of engagements, the rules that are expected from someone. And by someone, I mean
[25:52.430 --> 25:59.290]  the MDM. These things need to be defined and clarity needs to be given to what the expectation
[25:59.290 --> 26:07.430]  of a secure device is. I want to see these things on black and white. I don't want to have the
[26:07.430 --> 26:14.850]  conversation anymore. I want a call to action to make things better, to change it now before legacy
[26:14.850 --> 26:25.450]  comes and bites us in the ass. Because every year we wait, every year we take, it adds so much more
[26:25.450 --> 26:33.030]  to the problem. At one point, the problem will become unmanageable if we don't do something now.
[26:33.830 --> 26:41.630]  If you as a researcher find a vulnerability, do the proof of concept, reach out,
[26:42.530 --> 26:49.070]  make things better, but don't just find a problem, find a solution. Because
[26:49.830 --> 26:56.130]  finding problems are easy, breaking in is easy, but it's finding a way for things to work better
[26:56.130 --> 27:02.190]  that is going to change the world fundamentally. And it's not one person or two people,
[27:02.190 --> 27:08.890]  but a whole collective effort that will change the future of connected devices.
[27:12.170 --> 27:20.050]  Thank you very much and please feel free to reach out. Hit me up on Twitter, email me,
[27:20.050 --> 27:24.610]  go comment on my blog. But I'm looking forward to your questions and I'm looking forward to
[27:24.610 --> 27:29.590]  the discussion. And thank you for giving me an opportunity to get on my soapbox and for once
[27:29.590 --> 27:34.110]  be taught, shout in a room about things that are making me angry.
